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(54) Permit for controlling access to services in protected memory systems 

(57) One embodiment of the present invention pro- 
vides a method and an apparatus for controlling access 
to services in a protected memory system. The method 
makes use of a permit, which includes an access con- 
trol mechanism (500) that resides in a memory space 
that is protected from a user of the permit. The method 
includes receiving a request for a service through a per- 
mit, the permit comprising an object (300) defined within 
an object-oriented programming system. In response to 
the request, the method activates an access control 
mechanism within the permit. This access control 
mechanism controls access to the service and resides 
in a memory space that is protected from a user of the 
permit, such that the access control mechanism is trig- 
gered by invoking (502) a method (306-310) on the per- 
mit. If the access is allowed, the method accesses the 
service by performing an invocation (506) on a control- 
led object (320). This controlled ok^ect includes meth- 
ods (324-328) to perform the service, and is othenwise 
protected from the user of the permit. Another variation 
of the above embodiment includes receiving, at a permit 
issuing authority, a request for the permit from an entity ^ 
(such as a person, a computer program or a corrputer 
process) requiring access to the service. If the request 
includes valid authorisation information, a permit is, _ 
issued (412) to the entity. A further variation of the 
above emtKxliment indudes creating a copy of the per- 
mit and transferring the copy to an entity requiring 
access to the service. 
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Description 
BACKGROUND 

[0001] The present invention relates to protection 
mechanisms in cortpmer systems. More specifically 
the present invention relates to a method and an acoa ' 
ratus for controlling access to services provid^ by 
other applications in protected memory systems. 
[00021 .Programming languages such as the Java'" 
programming language (developed by SUN Microsys- 
tems.. Inc. of Palo Alto. California) and associated sup- 
porting interfaces presently provide- a reliable and' 
secure infrastructure to support the transfer of an appli- 
cation across a computer netvrark. and to run the appli- 
cation on a wide range of computing platforms. 
Because of developments such as Java, it is becoming 
increasingly common to load an application, such as a 
Java applet, from a remote server onto alocal machine 
fl^t ^""^""^^ application on the local machine ' 
[0003] However, present computing systems are not 
designed to allow computer applications from different 
. vendors to interact with each other in a controlled way 
so that the applications can work together to accomplish 
a given task. One problem in doing so is that appfication 
vendors typically want to control the way in which these 
jnteractions take place. For example, it may be useful for 
fP''cat»r,, to access capital gains Jnformation 
from a home brokerage application. However, the home 
brokerage application needs to protect the privacy of 
the customer's portfolio. Hence, the.lax application Ln- 
not be^given unrestricted access portfolio data from the 
home brokerage application. 

[OOM] Historically; the task of controlling accesses to' 
' th^rr systems has been -handled 

"^'^ -mechanisms, such' as hardware - 
capabilrties systems. However, such special-purpose ■ 
c^^^ '% not present on all computing platfS. \ 
Consequently, rt is not practical to use such hardware to ' 
. confroi access to services for portable applications '•■ 
such as a Java- applet, whi* is designed^ ' 
across a vyide range of conpuang platforms.. 



pe^mrt^such that the access control mechanism is trig- 

IS afo^L^T"" ^ 2^"*"°^ °" "^"^^ 
^ allowed, the method accesses the service by per- 

. ^rj^^^ll?^*^*'"" °" ^ *iect. -mis con- 

aZt •"""^'^ "'^'^^ '° perform the service. 
^JL^ ^'^ "s«^ °* 'f'e permit 

: , Another variation of the above embodiment indudes 

' ^ ^^"^ 3 ^«'"est for the 

permit from an entity (such as a person, a computer 

. service If the request includes, valid authori2ation infor- 

Z ^1""" '""'^ A further varia- 

ton of the above embodiment includes creating a copy 
of the permit and transferring the copy to an erZ 
IS. requiring access to the service. 

J0OO6] Thus, the present invention provides a method 

.^tT ^ ^^"'^^ P"^^^^ by another 

application. This method does not rely on hardware 
access control mechanisms, aixl hence can be 
^ employed by a portable application across a wide range 
of computing platforms. ^ 

BRIEF DESCRIPTION OF THE RGURES 
2S [0007] - 



SuiMMARY- 

iqOOS] One embodiment of the present invention pro- 
vKies a method and an apparatus for controlling access 
^services provided by other applications.. The method^ 
rnakes use of a permit, which includes an:aGcess con- 

D^^T"' ■ """^^ ^ "^^y that is 
protected from .a user of, the .permit. The . method 
mcludes receiving a request for a service through a per- 

otJe^ or^n """^"^"^ object dofined within an 
ot^ect-onented programming - system. . In response to 
me request, the method activates an accSTcoirS 
mechanism within the , permit. , This access cort o 
mechanism controls access to the service and resides 
•n a memory space that is protected from a user of the 



FIG. 1A illustrates code modules working together 
within computer system in accoidance with an 
embodiment of the present.invention 
30 FIG. . IB illustrates a number of computer nodes 
coupled together through a network in accordance 

an embodiment of the present invention 
FIG.,2 Illustrates the process of accessing a service 
|n accordance with an embodiment of the present 
35 ..invention. k"=ociii 

FIG. 3 illustrates the structure of a permit object 

and a controlled- object 320 in accordance wHh an 
embodiment of the present invention 
FIG. 4 is a flow Chart illustrating the process of cre- 
ating a permit object in accordance with an embod- 
- . iment of the present invention. 

FIG, 5 is a flow chart illustrating the.process of 
using a permit object to access a service in accord- 
""than embodiment of the present invention. 

DETAILED DESCRIPTION 

. W008] The following description is presented to ena- 
.n ^J^ P^ ski'led .in the art to make and use the 
so . 'rventon. and is prov^ided in the context of a particular 
appl-cation and .te requirements- Various modifications 
!^ embodiments will be readily apparent to 

dTn ""^ general principles 

. d^ned herein may be applied to other enixxJiments 

t"!!!*^ 1^°"^ '^^^"S fr"-^' the spirit and 

scope of the present invention. Thus, the present inven- 

' TJ^ k . f^u^ '° '° errtxxJiments 

shown, but IS to be accorded the widest scope consist- 
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ent with the principles and features disclosed herein. 

Distributed Computer System ' ' 

[0009] FIG. 1 A illustrates code modules 1 02 and 104 5 
working together within computer system 100 in accord- 
ance with an embodiment of the present irivention. In 
order to work with code module 104. code module 102 
requests services from code module' 104." Similarly, in 
order to work with code nnodule 102, code nxxlule 104 w 
requests services from code module 102. Access to 
services between modules 102 artd 104 is controlled 
through the permit structure described in more detail 
with reference to FIGs. 3-5 below. 

[0010] For purposes of this detailed description, a is 
service is a function made available by a first application 
to other applications. This function may provide the 
other applications with access to data or to computa- 
tional resources from the first application. A protected 
memory system is a system that facilitates protection of 20 
selected regions of memory from an application running 
on the system. 

[0011] FIG. 1B illustrates how the present invention 
can be used in a client-server computer context in which 
a number of computer nodes coupled together through 25' 
a network 130 in accordance with an embodiment of the 
present invention. In FIG. 1. servers 110 arxJ 120 are 
coupled to third-party system 140 tlrough network 130. 
Network 1 30 generally ret ©-s to any type of wire or wire- 
less link between computers, including, but not limited 30 
to, a local area network, a wide area networK or a com- 
bination of networks. In one embodiment of the present * 
invention, network 130 includes the Internet. Servers - - 
110 and 120 -can be any nodes on a computer network 
including a mechanism for servicing requests from a cli- 33 
ent for conputational or data storage resources. Third- ' 
party system 1 40 may be any node a computer network 
communicating with servers 110 an6 1 20 that is able to 
downlo^ code and/or data from servers 11 0 and 1 20. 
[0012] In the emlxxliment illustrated in FIG. 1, server 40 
110 contains server code nrxxiule 112. arxi server 120 
contains client code rrxxiule 122. Server code nnodule 
1 1 2 and dient code module 1 22 include nriodular pieces 
of code that can operate together on third-party system 
140. The dashed lines in FIG. 1 represent server code 4S 
module 112 and client code nrxxlule 122 being down- 
loaded onto third-party system 140 across network 130. 
This downloading process can take place in a number 
of ways. In one embodiment of the present invention, 
server 110 includes a web site that can be accessed by -so 
a user on third-party system 140 to download server 
code module 1 1 2 onto third-party system 140. Corre- 
spondingly, server 120 includes a web site that can be 
accessed by a user on third^jarty system 140 to down- 
load dient code module 122 into third-party system 140.' 55 
In another embodiment, server code module 112 and* 
client code nruxJule 122 are not downloaded across net- 
work 130. Instead, they are transferred from servers 



1 10 arxJ 120. respectively, to third -party system 140 by 
way of computer storage media, such as a computer 
disk. 

[0013] Once server code module 1 12 arKj client code 
module 122 are located on third-party system 140, they 
can be integrated to work together as is illustrated in 
FIG. 1 . For exanrple, in providing a service to client code 
module 122. server code module 112 might retrieve 
data from a database for client code module 1 22. Alter- 
natively, server code module 1 12 might perform a com- 
putational operation for dient code module 122. This 
integration process may involve determining whether 
dient code'module 122 has been conferred the right to 
access services from server code module 112. In the 
reverse direction, this process may involve determining 
whether server code module 112 has been conferred 
the right to access services from client code module 
122. 

Prociess of Accessing a Service 

[0014] FIG. 2 illustrates the process of accessing a 
service in accordance with an embodiment of the 
present invention. FIG. 2 illustrates interactions 
between server gate 202. system 204 and client code 
module 122 (from FIG. -1). Note that the process for 
accessing a service illustrated in FIG. 2 represents only 
one possible method of obtaining access to a service. In 
general, the present invention applies to any pieces of 
code working together in a computer system. Server 
gate 202 is a mechanism that provides permits to prop- 
erly authorized requesters. 

[0015] Foi' purposes of this detailed description, a per- 
mit is a token held by ah entity, which allows the entity to 
access a service. In one enntx)diment of the present 
invention, a permit indudes an object defined within an 
object oriented prograrhming' system that facilitates 
accesses to a collection of services. 
[0016] Server gate 202 includes an access control 
mechanism that controls access to services provided by 
server code module 1 12 (from FIG: 1). This access con- 
trol mechanism can require varying levels of authentica- 
tion from a requester of a perrnit. In one embodiment of 
the present invention, server gate 202 is located within 
server code module 112 oh third-party system 140. In 
another embodiment, server gate 202 is located within 
server 110 itself, and is accessiad via communications 
across network 130. System 204 includes a mechanism 
for estak^ishing that'client code nnodule 122 is properly 
authorized to access services provided by server code 
module 1 12. To this end. system 204 is implemented in 
a nurrt)er of ways. In one embodiment, system 204 is 
implemented by code that is part of third-party system 
140.'ln another enntoodiment, system 204 may be imple- 
mented as part of server code module 112 within third- 
party system 140, 

[0017] The process illustrated in FIG. 2 operates as 
follows. Client code module 122 is assumed to already 



3 



8NSDOCID: <EP 0965917A1_I_> 



EP0 965 917 A1 



exist within third-party system 140. In order to access a 
desired service, client code module 122 requests a 
"ticket" for a ''role" to access a collection of services 
from server code module 1 12. A role defines a set of 
operations to be performed by server code module 112. 5 
Certain roles may be more limited than other roles. For 
example, if server code module 112 maintains a compu- • 
ter f ile system, one role may include only the operation 
of reading afile from the file system. Another more pow- 
erful role may include the operations of reading, writing ,0 
and deleting files from the file system. . 
[0018] In response to the request, system 204 exam- 
ines client code module 122. to determine if client code 
module 1 22 includes proper authorization for the role. In 
one embodiment of the present invention, this examina- 15 
tion includes examining a certificate chain. This process 
rs described in more detail in a coiDending European 
Patent Application No.; entitled "Controlling Access to 
Services Between Modular Applications." correspond- 
ing to U.S Patent Application Serial No, 09\ 106. 567 20 
which is hereby incorporated by reference in order to 
describe this process. 

[001 9] If client code module 1 22 is properiy authorized 
for the role, system 204 issues a ticket for the rote, and 
this ticket is given to client code module 122. Next client 2s 
code module 122 passes the ticket to server gate 202 
Server gate 202 checks the ticket to ensure that the 
ticket fs valid. If it is valid, server gate 202 sends a per- 
mit for the service to client code module 122 This per- 
mit allows client code module 122 to access the 30 
. services defined by the role. In one entxxiiment of the 
present invention, this permit is an object defined within 
an object-onented. programming system. This object 
allows client code module 122 to pertorm a set of meth- 
ods that comprise the role. After the permit is sent .35 
sen/er gate 202 invalidates the ticket, so that it cannot - 
be used again. Since client code module 1 22 remains in 
possession of the permit, client code module 122 will be 
able to access services using the permit, and hence no 
longer needs the ticket. : 



Permit Ob ject 

[0020] FIG. 3 illustrates the structure of a permit 
object 300 and controlled c*)ject 320 in accordance with 45 
an embodiment of the present invention. Permit object 
300 (s typically held by a client code module, such as di- 
ent code module 122 (from FIG. 1). which requires 
access to services provided by a server code module 
such as server code module 112 (from FIG. 1) Server so 
code module 112 maintains controlled object 320 
which contains code and data used to implement the 
services. Note that the embodiment illustrated in FIG 3 
IS implemented through objects defined: within an . 
object-onented programming system. However the 55 
invention is not limited to object-oriented programming 
systems. ^ ^ 

[0021] Permit object 300 includes a number of compo- 



nents including controlled object pointer 302 boolean 
vector 304. method-0 pointer 306. method-1 pointer 
308. method-N pointer 310. permit creation method 
312. permit expiration information 314 and permit log 
316. . 

[0022] Controlled object pointer 302 points to controi- 
-ied.f^ject 320. which is maintained by server code mod- 
ule 1 12. and thereby allows the holder of permit object 
300, to access services associated with controlled 
object 320 within server-code module 112. Controlled 
object pointer 302 is stored in a memory that area that 
IS protected from accesses by client code module 122 
aient code module 122 cannot directly read or modify 
controlled object pointer 302. Client code module 122 
cannot access controlled object 320 directly. In order to 
access controlled object 320. client code module 122 
must ask the system to access controlled object 320 
through controlled object pointer 302. Similarly, the 
other data items within permit object 300 are protected 
so they cannot be directly read or modified by client 
code module 122. This memory protection ensures that 
client code module 122 must access services associ- 
ated with controlled object 320 by asking the system to 
access the services. This enables the system to restrict 
access to the services in a manner that is specified bv 
the permit. 

[0023] As mentioned above, this type of memory pro- 
tection can be provided by using the Java'" program- 
ming language and si^orting interfaces. The Java'" 
programming language supports memory protection 
down to the object level. Under the Java model, the only 
way to access data within an object is by invoking meth- 
ods supported by the object Data within an object is 
othenvise protecied from memory references - through 
fi stray pointer for exanple. Since the Java'" program- 
: ming language can be ported across a wide range of 
computing platforms, this object level memory protec- 
tion can be provided across a wide range of computing 
platforms. However, note that it may be possible to get 
around the protection mechanism by attacking the inter- 
face between the Java programming language and the 
operating system on a particular computing platform In 
order to prevent this type of attack, the Java'" memory 
protection scheme can be extended into the hardware 
of a computing platform. . 

[0024] Boolean vector 304 contains entries corre- 
sponding to methods provided by controlled object 320 
These methods implement the services associated con- 
trolled object 320: If an entry includes an "ALLOWED" 
value, this indicates that the holder of permit object 300 
IS allowed to access the corresponding method that 
implements the service from controlled object 320 If the 
entry includes a "NOT ALLOWED" value, this indicates 
the holder of the permit is not allowed to access the cor- 
responding method. In this way. permit object 300 spec- 
if les which sen^ices the holder of the permit is allowed to 
access. Since boolean vector 304 is located in pro- 
tected memory, a holder of permit object 300 cannot 
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modify boolean vector 304 to gain unauthorized access 
to a service. Note that there are many possible ways to 
indicate that particular methods are not allowed. In 
another embodiment, methods within permit object 300 
are coded to call a corresponding method in controlled 
object 320. Otherwise, they are coded to indicate that 
the method is not allowed. 

[0025] The methods specified in controlled object 320 
are accessible through method pointers within permit 
object 300. These method pointers include method-0 
pointer 306, method-i pointer 308 and method-N 
pointer 31 0.'Client code module 122 must access meth- 
ods 324, 326 and 328 through these method pointers 
306, 308' and 310. Method-0 pointer 306 points to 
method-0 324 within controlled object 320. Method- 1 
pointer 308 points to method-1 326 within controlled 
object 320. Method-N pointer 310 points to method-N 
328 within controlled object 320. These method pointers 
reside in protected memory so that client code module 
122 must access the methods through the system, 
[0026] In the illustrated embodiment, permit object 
300 additionally includes permit creation method 312, 
which allows a holder of permit object 300 to create a 
copy of permit object 300. and to transfer the copy to 
another application. This allows client code module 122 
to farm out a sub-task requiring services from controlled 
object 320 to another module. Note that permit creation 
method 312 allows only less powerful copies of permit 
object 300 to be made. In other words, copies of permit 
object 300 can access at most the same methods from 
controlled object 320. and possibly fewer methods. 
[0027] Permit object 300 additionally includes permit 
expiration information, which specifies some type of 
lifespan limitation for the permit In one embodiment." 
this is accomplished by specifying a certain time period 
during which the permit is valid. In another embodiment, 
this is accomplished by requiring that the system first 
check in a central database to see that the permit 
remains still valid. - "'' 

[0028] Permit object 300 also includes permit log 316, 
which records a log of access requests to permit 300. 
This log can be used for security purposes to monitor 
how permit object 300 is being used. Alter natively, a log 
of access requests can be maintained within controlled 
object 320. ' • ■ ' . 

[0029] Controlled object 320 contains data 322. which 
is used by methods 324. 326 and 328 to implement 
services associated with controlled object 320. For 
example, data 322 may contain file system data and 
methods 324. 326 and 328 may specify file system 
operations. / v 

Permit Creation 

[0030] FIG. 4 is a flow chart illustrating the process of 
creating a permit object in accordance with an en^rbodi- 
ment of the present invention. This flow chart describes 
in more detail the operations performed by server gate 



202. which were described previously with reference to 
FIG. 2 above. The system starts at state 400 and pro- 
ceeds to state 402- In state 402. client code module 1 22 
performs an invocation on server gate 202 to make a 

5 new permit. As mentioned above, this irrvocation 
' includes a ticket for a role as a parameter. Ttie system 
then proceeds to state 404. In state 404, server gate 
202 authenticates the ticket, and if it is valid, server gate 
202 makes a new permit object 300. This process may 
'include locating a controlled object 320 to associatfe 
with permit object 300. or if necessary, making a new 
controlled object 320 within server code module 112. 
The system, next proceeds to state 408. In state 408, 
controlled object pointer 302 (from FIG. 3) is assigned 

15 to point to controlled object 320. The system next pro- 
ceeds to state 410. In state 410, the system sets access 
control flags (entries in boolean vector 304) to specify 
which methods the. holder of the permit is allowed to 
invoke. The system next proceeds to state 410. In state 

20 410, permit object 300 is returned to client code module 
122. The system next proceeds to state 414. which is an 
end state. 



Use of Permit Object 



25 



[0031 ] FIG. 5 is a flow chart illustrating the process of 
using a permit object to access a service in accordance 
with an embodiment of the present invention. The sys- 
tem starts at state 500 and proceeds to state 502. In 

30 state 502, client code module 122 (from FIG/ 1) invokes 
a method on permit object 300 (from FIG. 3). The sys- 
^ "*tem proceeds to state 504. In state 504, the system 
checks access control flags corresponding to the 
niethod: This entails looking up an entry in boolean vec- 

35 tor 304 corresponding to the invoked method. If this 
access control flag indicates the method is allowed, the 
system proceeds to state 506: Otherwise, the system 
proceeds to state 510. 

[0032] In state 506 the access is allowed, so the sys- 
40 tem invokes the appropriate method on permit object 
300. which causes a corresponding method to be 
invoked on controlled object 320 with the appropriate 
parameters. The system next proceeds to state 508, In 
state 508, the system waits for the invocation to com- 
' 45 - plete, and then returns a result to client code module 
' 1 22. The system next proceeds to state 512, which is an 
erxJ state. 

[0033] In state 510, the method is not allowed. In this 
case, the system indicates to client code module 122 

50 that the method is not allowed. This can be done in a 
nunrber of ways. In one embodiment, of the present 
invention, the system causes an exception to occur in 
the execution stream of a processor performing the 
method invocation. In another embodiment, the system 

55 : sets a global variable to indicate that the attempted use 
= of permit object 300 failed. In yet another embodiment, 
• the invocation to permit olDject 300 returns a NULL 
value. The abc\/e process is repeated for successive 



5 



BNSDOCID: <EP 096591 7A1_L> 



EP 0 965 917 A1 



10 



invocations on permit object 300. 
[0034] The foregoing descriptions of emixxJiments of 
the invention have been presented for purposes of illus- 
tration and description only. They are not intended to be 
exhaustive or to limit the invention to the forms dis- 
closed. Accordingly, many modifications and variations 
will be apparent to practtioners skilled in the art. 

Claims 



8. 



1 . A method tor controlling access to services in a pro- 
tected memory system, comprising: 

receiving a request for a service through a per- 
mit, the permit cor^rising an objea (300) 
defined within an object-oriented programming 
system: . _ " 

in response to the request, activating an 
access control mechanism (500) within the per- 
mit, the access control mechanism controlling 
access to the service and residing in a memory 
space that is protected from a user of the per- 
mit, such that the access control mechanism is 
triggered by invoking (502) a method (306-310) 
on the permit; and 

if the access is allowed, accessing the service. 

2. Tfie method of daim 1 , wherein the .access control 
mechanism (500) provide access to the service by 
performing an invocation (506) on a controlled 
object (320). the controlled object including a 
method (324-328) to perform the service, and oth-' 
enwise being protected from the user of the permit. 

3. , The method of daim 1 or claim 2. further compris- ' 

•ng If the access is not altowed. indicating (510) to 
an entity requesting the service that the access to 
the service Is not allowed.. 



■ ,^!.!^ °^ ""^"^ ^ °' '^^'^ 2. wherein the per- - «, 
niit (300) IS defined within the Java™ programming ' " 
language and si^jporting interfaces. 

5. The, method of any oire of daims 1 to 4. wherein 
data (322) protected by the .permH (300) can only « . 
be accessed through methods (306-310) invoked 

. on the permit. s . . 

6. The method of any one of daims 1 to 5 further 
comprising: ' 



receiving, at a. permit issuing authority, a 
request fpr the permit from an entity requiring 
. access to the service; and . 
if the request includes valid aulhorisatfon infor- 
mation, issuing the permit (41 2) to the entity. ' 



10 



so 



35 



30, 



35 



comprising creating a copy of the permit (300) and 
fransferring the copy to an entity requiring access to 
trje. service. 

The method of daim 7, wherein the copy of the per- 

ST^f"^ ^ '^^ "^^^ ♦'^e permit 

(300) that It was copied from. 

The method of any one of claims 1 to 8 further 
comprising determining whether the permit has 
been revoked before accessing the service, and 
been^evoked. indicating (510) the access is not 



10. The method of any one of daims 1 to 9. further 
roi^rising recording the access request in a log 
(31 6) assodated vwth the permit. 

11. The method of any one of claims 1 to 10 wherein 
activating the access control medianism indudes 
determining (314) whether the permit has expired. 

12. The method of any one of claims 1 to 11. wherein 

"^^^a^sm includes a pointer 
(3«tt).to the controlled object (320). the pointer 
residing in the memory space that is protected from 
Ihe user of the permit. 

13. Tfie method of any one of claims 1 to 12, wherein 
Jlol'^T '^«^f«"'sm includes a method 
(324-328) to be invoked to perform the service 
^wherein If access is not allowed, the method (324^ 

. 328) does not perform the service, but instead indi- 
' T^J^'°^ ■'^^ ^"^^ ^° service is not 
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7. The method of any one of claims 1 to 6. further 



The method of any one of claims 1 to 13. wherein 
the access control mechanism includes a variable 
(304) associated with a method to be invoked to 
perform the service, wherein the variable indicates 
whether the access is allowed. 



15. A computer readable , storage medium storing 
instructions that when executed by a computer 
cause the computer to perform a method for con- 
trolling access to services in a protected memory 
system, comprising: 

receiving a request for a service through a per- 
mit, the permrt conprising an object (300) 
defined within an object-oriented programming 
system; ^ 

in response to the request, activating an 
access control mechanism (500) within the per- 
mit, the access control mechanism controlling 
access to the service snd residing in a memory 
space that is protected from a user of the per- 
nFtit. such that the access control mechanism is 
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triggered by invoking (502) a method (306-310) 
on the permit; and 

if the access is allowed, accessing the service 
by performing an invocation on a control- 
led object (320), the controlled object including 
a method (324-328) to perform the service, and 
othenwise being protected from the user of the 
permit. ' ~ 

1 6. An apparatus for controlling access to services in a 
protected memory system, conrprising: 

a permit means through which a user can 
access a service, the permit means optionally 
comprising an object (300) defined within an 
object-oriented programming system; 
ah access control means (500) within the per- 
mit, the access control means controlling 
access to the service and residing in a mennory 
space that is protected from a user of the per- 
mit, such that the access control means is trig- 
gered by invoking (502) a method (306-310) on 
the permit; and 

a request processing means, in communication 
with the permit means, that is configured to 
receive an access request for the service 
through the permit means, and to activate the 
access control means, 

1 7. The apparatus of claim 16. wherein the access con- 
trol means '(500) is configured to provide access to ' 
the service by performing an irWocation (506) on a 
controlled object (320),' the controlled object includ- 
ing a method (324-328) to perform the service, and 
othenwise being protected frbrh the user of the per- 
mit (300). 

18. The apparatus of daim 16 or claim 17. whierein the 
request processing means is configured to indicate 
(51 0) that the access to the service is not allowed if 
the request processing means determines that the 
access is nofl allowed. - 

19. The apparatus of any one of claims 16 to 18, 
wherein the access control means (500) includes at • 
least one method (324-328) to' be irivoked to per- 
form the service.' • ■ r) 

20. The apparatus of any one of claims 16 to 19. 
wherein the permit (300) is defined within the 
Java™ programming language and supporting 
interfaces. 

21. The apparatus of any one of claims 16 to 20; 
wherein data (322) protected by the permit (3(M)) 
can only be accessed through methods (306-310) 
invoked on the permit* 



22. The apparatus of any one of claims 1 6 to 2 1 , f ur ther 
comprising a permit creation mechanism (400) that 
receives a request for the permit (300) from an 
entity requiring access the service, and if the 

5 ' request includes valid authorisation information, 
issues (412) the permit to the entity. 

23. The apparatus of any one of claims 1 6 to 22. further 
comprising a permit copying mechanism tfiat is 

10 configured to create a copy of the permit (300) and 
to transfer the copy of the permit to an entity requir- 
ing access to the service. 

24. The apparatus of any one of claims 16 to 23, 
15 wherein the perrhit copying mechanism is config- 
ured to produce the copy of the permit that allows 
access to fewer services than the permit (300) it 
was copied from. 

20 25. The apparatus of any one of claims 16 to 24. 
wherein the request processing means is config- 
ured to determine (504) whether the permit has 
been revoked before accessing the service. 

25 26: The apparatus of any one of claims 1 6 to 25, further 
comprising a log (316). associated with the permit, 
to record access requests. 

27. the apparatus of any one of claims 16 to 26. 
3o ' ' wherein the request processing means is conf ig- 
" ' ured to determine (314) whether the permit has 

■ ■ expired. 

' ' 28: A data structure contained in a computer readable 
35 storage medium for controlling access to services 
in a protected memory system, the data structure 

■ ' ^ comprising: 

an access control mechanism (500) within the 

40 data structure, the access control mechanism 

controlling access to the service and residing in 

' a memory space that is protected from a user 

of a permit (300). such that the access control 
mechanism is triggered by invoking (502) a 

45 ■ ' method (306-31 0) on the permit; arxJ 

an access control indicator (304) within the 
data structijre, the access control indicator 
specifying services the user can access, the 
access control indicator being protected from 

50 modification by the user. 

29. The data structure of daim 28, wherein the access 
control mechanism (500) indudes a pointer to 
code(324-328) that implements the service, the 

55 pointer residing in the menrwry space that is pro- 
tected from the user. ' 

30. The data structure of claim 28 or claim 29, wherein 
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the access control indicator (304) includes a varia- 
ble associated with a service, wherein the variable 
indicates whether access to a corresponding serv- 
ice is allowed. 

31. A computer program or applet encoding a set of 
computer instructions for controlling access to serv- 
ices in a protected memory system, which when 
running on a computer is adapted to perform the 
method of any one of claims 1 to 1 4. jo 
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